Technical Field
This disclosure relates generally to web application security and in particular to a method and system for enabling different client contexts to share the same session information.
Background of the Related Art
It is known in the prior art to provide so-called Web portals, which are web-based mechanisms that centralize access to information, applications, and services for employees, customers, or partners. A Web portal delivers a consolidated view that lets users access electronic resources of the organization using a standard technology (a web browser), simply and efficiently. Within a Web portal or like environment, typically a proxy or web server acts as a front-end “point of contact” to a set of back-end applications or application components. In this type of environment, it is desirable that the mechanism used to provide authentication and session management at the web portal layer should also provide these functions for any back-end applications that are included in a consolidated view.
In this type of environment, approaches to session management typically have each back end application or application component requiring its own session state management, and each such application or component may implement its own session management technique. Where an end user is accessing multiple applications within a single enterprise, his or her browser ends up managing independent session management items (often as many as a different item per application). Typically, in this environment, these items are HTTP cookies, as the behavior of such cookies (although not intended for session management) provides reasonable session management. HTTP cookies (see IETF RFC 2109) provide a way of managing sessions and state between web browsers and web servers using the HTTP protocol. These cookies typically are stored in the web browser's session cache, sometimes called a cookie jar.
In web-based session management systems, currently there exists no mechanism to share session information between different user agent contexts in a secure way. A “context” is a client-server operating state with respect to a particular user agent application, on the one hand, and a designation application, on the other hand, following authentication of the client to the server. Typically, if a user, after establishing session A in one context A, then switches to context B, the previous session information A is no longer available to the client user agent. This can lead to multiple authentication requests for the same user.
The most common existing solutions to this problem are based on URL rewriting or embedding the original session information in a cookie, but each such approach has its own disadvantage. Thus, for example, in the URL rewriting technique, the original session identifier is passed from the client to the web application in a URL string, e.g., as a URL parameter. In the cookie approach, the original session identifier is written to a persistent jar on the client side and then passed to every context. In both cases, however, because the original session information is transmitted with the response, it is vulnerable to security attacks such as unauthorized session identifier manipulation, or stealing of user credentials. In an alternative approach, the real session information is transformed into a different format, and each new client request includes this transformed information to use the original session information. The transformed entity typically is long-lived on the server. Still other approaches require special client-side software.
There remains a need in the art to provide for session sharing across multiple client contexts.